auto merge of #710 : alexcrichton/cargo/metadata, r=wycats
authorbors <bors@rust-lang.org>
Wed, 22 Oct 2014 19:45:38 +0000 (19:45 +0000)
committerbors <bors@rust-lang.org>
Wed, 22 Oct 2014 19:45:38 +0000 (19:45 +0000)
commitc1f7d620d4b1b91cfa31a1501aad15027358efad
tree663944ac88cc0b8cc49d4aa5f3d05eb5801b6ed8
parent41dbbf24bee4e9fe7994415396ab893af4588728
parent9879cc55f62537f304dd2cfdd1eca419313d9426
auto merge of #710 : alexcrichton/cargo/metadata, r=wycats

In terms of future compatibility, Cargo may wish to add more information to
lockfiles in the future. For example, the minimum required Rust version may one
day be encoded into a lockfile.

One of the major goals of a lockfile is for it to rarely change, and when it
does change the diffs should be minimal. In terms of adding more information to
the lockfile in the future, this presents a problem for older Cargo clients:

1. Cargo 2.0 adds a minimum required version of rust under the metadata.rustc
   key of the lockfile.
2. Cargo 1.0 is then used to update the `foo` dependency in the lockfile. When
   regenerating the lockfile, Cargo 1.0 discards the metadata inserted by Cargo
   2.0.

In order to future-proof ourselves in allowing new metadata in the future, Cargo
is growing support now for transporting an opaque payload of metadata from one
version of a lockfile to a new versions. This should solve the problem presented
above.

This metadata section is designed to be safely ignored by older Cargo versions
(may just have some surprising behavior), while still allowing newer versions of
Cargo to process the data. For example Cargo 2.0 would gracefully fail on an
out-of-date rustc, while Cargo 1.0 may just present an obscure error message.

r? @wycats